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REMARKS 

Thi$ amendment is responsive to the Office Action dated April 29, 2005. Applicant has 
cancelled claitns 19 and 25. Tn addition, Applicant has amended claims 1, 13, 14, 18, 20, 21, 22, 
23, 27, 31 and 39, Claims 1,4-18, 20-24 and 26-44 are pending upon entry of this amendment. 

Claim Objection 

In the Office Action, the Examiner objected to claims 1,13,18 and 39 for certain 
informalities. Applicewit has amended the claims for purposes unrelated to patentability as 
requested by the Examiner. 

Claim Rejection Under 35 S 102 

In the Office Action, the Examiner rejected claims 1, 5, 9, 27, 31-33 and 37-38 under 35 
U.S.C. 102(e) as being anticipated by Cain (USPN <5,697,325). Applicant respectfully traverses 
the rejection, Cain fails to disclose each and every feature of the claimed invention, as required 
by 35 U.S.C. 1 02(e), and provides no teaching that would have suggested the desirability of 
modification to include such features. 

Before addressing the specific claim rejections. Applicant provides some preliminary 
commeaits to clarify certain technical differences between the cited references and Applicant's 
claimed invention. 

In general, routing devices use different types of protocols to communicate with other 
routing devices and ultimately make routing decisions. One common class of routing protocols 
is path vector touting protocols (also referred to as distance-vector routing protocols) that are 
used to commiinicate available routes within a network. In particular, path vector routing 
protocols exchange advertisement messages to announce new routes and withdraw routes. Each 
route delBines an available path (i.e,» a vector) through the network, such as {A"»B-»C-»D-^E-> 
F} , where A-F are different locations within the network. Routers that implement a path vector 
routing protocol exchange large sets of available routes, and witfidraw particular routes when the 
routes are no longer available. Based on this information, the routing devices select paths 
through the network for forwarding traffic. Common path vector routing protocols include the 
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Border Gateway Protocol (BGP), the Routing Informatioa Protocol (RIP), the Internet Gateway 
Routing Protocol (IGRP) and the Routing Table Maintenance Protocol (RTMP).^ 

In contrast^ some routing protocols do not exchange routes but instead exchange 
information describing the status of individual links (i.e., the physical communication 
connections between the nodes). This type of protocol is comtnonly referred to as a "link state 
protocol." Instead of communicating routes through networks, information is conveyed that 
describes the connectivity status of each particular link, i.e., whether the link itself is available. 
Link-state routers gather infoinaation about particular links and pass on the link state information 
to neighbors. Eventually, a link-state router has information about all links within a network, 
and then runs the Dijkstra shortest path algorithm to calculate the best path to each network- The 
most common link-state routing protocol is the Open Shortest Path First (OSPF) protocol. Other 
link-state routing protocols includes the Intentiediate System to Intermediate System (IS-IS) 
protocol, the OSI protocol, and the NetWare Link Services Protocol (NLSP).^ 

In one sense. Applicant's claimed invention can be viewed as a hybrid routing protocol in 
which a path vectoring routing protocol that advertises routes has been extended to include 
specific lu^ failure information in certain situations. For example, when a link fails, the routing 
protocol advertises routes to be withdrawn but also includes link failure infbimation that 
describes the particular link that has failed. In this manner^ the technique can be viewed as 
bridging a gap between path vector routing protocols and link state protocols known in the art. 

Claims I, 5 and 9 

Apphcant's claim 1 requires generating link failure infoimation identifying a failed link 
within a computer network, and communicating an update message to routers within the 
computer network in accordance with a routing protocol. Amended claim 1 requires that the 
update message request specifies routes through the computer network that rely upon the failed 
link and request withdrawal of the routes specified in the update message , and that update 
message fijrther incorporates the link failure infoimation to identify the failed link. 



' Sheldon, Encycl opedia of Networking & Tclccommmiications, McGraw-Hill, pg 741. 
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Thus, claim 1 requires both that the update message specify routes to be withdrawn as 
well a$ the link failure information that identifies the failed Jirik. 

In coTitrast, Cain describes use of a conventional link state protocol and specifically refers 
to OSPF and IS-IS. As explained above, OSPF and IS-IS referred to by Cain on coL 1, lines 20- 
25 and cited by the Examiner are very well known link state protocols. As described by Cain, 
these conventional link state protocols send link state advertisements (LSAs) to communicate 
state infonnation for particular links. However, it is well known that link state routing protocols 
do not describe actual routes (i.e., vectors) through a network, as do path vector routing 
protocols. 

For example, col. 2, lines 50-57 and col. 5, lines 21 -25 of Cain* as cited by the Examiner, 
describe a conventional "LSA protocol message" that indicates link failure. Cain makes clear 
that the receiving node removes the "failed communication link** from its topology database. In 
this fashion, Cain is describing conventional a link state protocol that communicate link 
information, not actual routes, as do path vectoring routing protocols. 

For at least diese reasons, Cain does not teach or suggest a protocol in which an update 
message has been extended to specify both: (1) one or more routes to be withdrawn, and (2) link 
failure information that identifies a fail link. This hybrid approach is not taught or suggested by 
Cain. 

With respect to claim 5^ the portion of Cain cited by the Examiner describes the node 
automatically deleting the link status information from a cache after a predetermined period of 
time. In contrast, Applicant's claim 5 requires that the link failure information included within 
the update message itself specify a time period for using the link failure information, Cain does 
not teach or suggest a routing protocol in which an update message between routers specifies a 
time period for using link failure information, as required by claim 5. 

In order to support an anticipation rejection under 35 U.S.C, 102(e);, it is well established 
thai a prior art reference must disclose each and every element of a claim. This well known rule 



-12- 



PAGE14/19*RCVDAT7/27I2005 5:36:00 PMIEastemDaylightr^^^ 



07/27/2805 15:34 6517351102 



SHUMAKER & SIEFFERT 



PAGE 15/19 



Application Number 09/810,986 
Responsive to Office Action mailed ApriJ 29, 2005 

of law is commotily referred to as the "all-elements rule.'*^ If a prior art reference fails to 
disclose any element of a claim, then rejection under 35 U,S,C. 102(e) is improper. 

Cain fails to disclose each and every limitation set forth in claims 1, 5 and 9. For at least 
these reasons, the Examiner has failed to establish a prima facie case for anticipation of 
Applicant's claims I, 5 and 9 under 35 U-S.C. 102(e). Withdrawal of this rqectionis requested. 

Claim 27, 31-33 and 37-38 

Applicant has amended claim 27 to include subject matter that the Examiner indicated as 
allowable. In particular. Applicant has amended claim 27 to require that the control unit forward 
the packets as if the failed link has been restored upon expiration of a valid time period 
associated with the link failure information. For at least these reasons, claims 27-38 are in a 
condition for allowance. 

Claim Rejection Under 35 U>S.C. S 103 

In the Office Action, the Examiner rejected claims 4, 7-8, 1 0-13, 15, 1 8, 21-26, 30 and 
39-43 under 35 U.S.C. 103(a) as being unpatentable over Cain in view of Agarwal et al (USPN 
6,760,777)* In addition, the Examiner rejected claims 16-17 and 34-36 under 35 U.S.C. 103(a) 
as being unpatentable over Cain in view of Agarwal et al. and in further view of Hardjono 
(USPN 6,425,004). 

Applicant respectfiilly traverses the rejectioa Tbe applied references fail to disclose or 
suggest the inventions defined by Applicant's claims^ and provide no teaching that would have 
suggested the desirability of modification to arrive at the claimed invention. 

Claims 4, 7-8, 10-1 1, 23 and 26 

With respect to claim 4, 7-8, 1 0-1 1 , 23 and 26, the Examine correctly acknowledges that 
Cain fails to describe the Border Gateway Protocol (BGP) or a path vector routing protocol of 



' See HyhrUech Tnc, v. Momchnal Antibodies, Inc., 802 F.2d 1367, 231 USPQ 81 (CAFC 1986) ("it is axiomatic 
that for prior art to anticipate under 102 it has to meet every elemerit of tfce claKued invention")' 
' Id, See also Levmar Marine, Inc. v. Bariem, Inc. 827 F.2d 744, 3 USPQ2d 1766 (CAFC 1987); In re Bond, 910 
F.2d 831, 15 USPQ2d 1566 (CATC 1990); CR. Bard, Inc. v. MP Systems, Inc., 157 F.3d 1340, 48 USPQ2d 1225 
(CAFC 1998); Oney v. Railiffl 182 F.3d 893, 51 USPQ2d 1697 (CAFC 1999); Apple Computer, Inc. v. Articulate 
Systems, Inc., 234 F.3d 14, 57 USPQ2d 1 057 (CAFC 2000). 
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any type. However, the Examiner asserts that BGP and path vectoring routing prx)tocols are 
known and reh'es on Agarwal solely for this premise. 

Applicant agrees that BGP and path vectoring routing protocX)ls are commonly used. 
However, as described above in more detail, and in Agarwal, routers use path vectoring routing 
protocols to advertise and withdraw routes (i.e., vectors of nodes) through networks. Other 
routers use link state protocols to convey state information for particular links. Agarwal makes 
clear that the described protocol specifies routes to be withdrawn (see, e.g., "rdBGP includes a 
procedure for propagation of multiple routes ... rdBGP includes a procedure for explicit route 
withdrawal based on route path attributes" at col. 7, 11,1-1 0). 

Thus, neither Agarwal nor Cain> either in combination or singularly, teach or suggest the 
use of BGP or any path vector protocol in which an update message has been extended to specify 
both: (1) one or more routes to be withdrawn, and (2) link failure information that identifies a fail 
link, as claimed by the Applicant. One of ordinary skill in the art would not look to BGP or a 
path vectoring protocol to convey link failure information as based on the teachings of Cain and 
Agarwal, as suggested by the Examiner. To the contrary, Cain and Agarwal merely describe 
known and commonly used link state protocols and path vectoring protocols, respectively. 
Neither Cain nor Agarwal, either singularly or in combination, suggest the hybrid protocol 
claimed by the Applicant that, at certain times, can be used to specify both routes to be 
withdrawn and related link feiiure information in order to reduce network flaps, 

For at least these reasons> the Examiner has failed to establish a prima facie case for non- 
patentability of Applicant's claims 4, T-S, 10-11, 23 and 26 under 35 U.S.C. 103(a). Withdrawal 
of this rejection is requested. 

Claim 13 

Regarding claim 13, the Examiner cites col, 2 of Cain that describes a node automatically 
starting a timer upon receiving a first LSA protocol message and updating its topology database 
if the node receives additional LSA protocol messages while the timer is running. Cain makes 
no mention of Ae timeout period other than it is "predefined.** 

In contrast^ Applicant's claim 13 requires that the link failure information included within 
the update message itself specify a valid time period for using the link feiiure information. Cain 
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does not teach or suggest a routing protocol in which an update message exchanged between 
rout<jTS specifies a time period for using link failxire infbnnatiort, as required by claim 1 3 . 

Claim 39 

In rejecting claim 39, the Examiner relies on portions of Cain, that describes a node 
automatically starting a timer upon receiving a first LSA protocol m^sage and updating its 
topology database if the node receives additional LSA protocol messages while the timer is 
running. For example, the Examiner refers to the "timer*' and cols. 4 and 5 of Cain. 

Applicant's claim 39, however, specifically requires receiving a message including link 
failure information that identifies a failed link as well as a storage time period for which the link 
ftilure information is to be stored by a receiving router. Thus, claim 39 specifically requires that 
the link failure information conununicated by the message specify both the failed link and the 
storage tiroe associated with the link fiiilure inibrmation. Cain does not teach or suggest a 
routing protocol tiiat can be u$ed to convey time periods for using link failure information for 
specific failed links, as required by claim 39. 

Claim 40-43 

Tlie Exaradner appears to have overlooked certain requirements of Applicant's claitns 40- 
43 . For example, claim 40 requires receiving a second message with the link failure message 
identifying the failed link; and forwarding the second message only if the storage time period for 
the link feilure message has expired* Claim 42 requires forwarding a message containing link 
failure infonnation only when the link failure information has not been previously roieived. 

The cited portion of Cain describes route computation (i.e., route selection) by a node and 

is does not refer at all to whether messages containing link feilure information are forwarded. 

For example, the cited portion states: 

When node C 1 12 receives a subsequent LSA protocol message relating to the 
faihjre of the communication link 104, from node B 106, node C 1 1 2 discards \hc LSA 
protocol message without comiputing new routes. . . . Having already removed the 
concmunication link 104 jfrom the list of conmnuni cation links associated with node B 106 
and computed new routes, node C 112 simply discards the subsequent LSA protocol 
message from node B 1 06. 
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This portion of Cain cited by the Examiner is clearly referring to route selection and is silent as 
to forvyarding of link failure infonnation ba$ed upon a storage time* 

Furthermore, claim 43 requires receiving a . tnessage including link failure infonnation 
identifying a failed link and at least one route having at least three nodes including a source node, 
a destination node and at least one intermediate nodes, wherein the failed link comprises a link 
coupling two of the nodes along the route. As stated above, link state protocols described by 
Cain do not specify routes. The Examiner concludes that it wouJd have been obvious to the 
pCTson of ordinary skill in the art 'to provide the identifies [sic] with source node, destination 
node and inteimediate node into the Cain's topology database." The Examiner overlooks 
Applicant's requirements that routing protocol message itself specify both: (1) link failure 
information identifying a failed link, and (2) at least one route having at least three nodes 
including a source node, a destination node and at least one intermediate nodes, wherein the 
failed link comprises a link coupling two of the nodes along the route. Such a routing protocol is 
not taught or suggested by Cain or the other refisrences, either singularly or in combination. 

For at least these reasons, the Examiner has felled to establish a prima facie case for non- 
patentability of Applicant's claims 40-43 under 35 U.S.C. 103(a). Withdrawal of this rejection is 
requested. 

Claims 16-17 and 34-36 

Claims 16-17 and 34-36 are allowable for at least the reasons set forth above with respect 
to the base claims on which they depend. Moreover, the applied references fail to disclose or 
suggest authenticating link failure information, as required by claim 16. Further, the applied 
references fail to disclose link failure information communicated in accordance with a routing 
protocol and that includes security data for authenticating an originator of the link failure 
information, as required by claim 32. 

Hardjono appears to describe authentication a source of a packet genially, but makes no 
mention of authenticating a source of link failure information or the inclusion of security data 
within a link failure message. For at least these reasons, the Examiner has failed to establish a 
prima facie case for non-patentability of Applicant's claims 16-17 and 34-36 under 35 U.S,C, 
103(a). Withdrawal of this rejection is requested. 
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Claims 18,20-22, 

In the Office Action, the Examiner objected to claim 1 9 a$ being dependent upon a 
rejected base claim, but indicated that claim 1 9 would be allowable if rewritten in independent 
fonn including all of the limitations of the base claim and any intervening claims. 

Applicant has amended claim 1 8 to include the subject matter of claim 1 9 and cancelled 
claim 19. For at least these reasons, claims 18. 20-22 are in a condition for allowance. 

Claims 23-26 

Applicant has canceled claim 25 and amended claim 23 to include subject matter that the 
Examiner indicated as allowable, Tn particular, Applicant has amended claim 23 to require 
forwarding a data packet to neighboring routers within the computer network according to the 
link failure information and a path vector routing protocol prior to e;^piration of the time period, 
and forwarding packets as if a failed link has been restored upon expiration of a time period. For 
at least these reasons, claims 23, 24 and 26 are in a condition for allowance. 



All claims in this application are in condition for allowance. Applicant respectfully 
requests reconsideration and prompt allowance of all pending claims. Please charge any 
additional fees or credit any overpayment to deposit account number 50-1 778. The Examiner is 
invited to telephone the below-signed attorney to discuss this application. 



CONCLUSION 
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8425 Seasons Parkway. Suite 105 



Reg. No.: 41,312 



St. PauL, Minnesota 55125 
Telephone: 651.735.1100 
Facsimile: 651.735.1102 
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